Variations

Netflix is only one technological option for implementing synchronous microservices.

There are various alternatives to the technologies of the Netflix stack.

Zuul2#

The Zuul project is not maintained very well anymore. An alternative might be Zuul2. It is based on asynchronous I/O so it consumes less resources and is more stable. However, Spring Cloud won’t support Zuul2. Another alternative might be Spring Cloud Gateway. The approach with Apache for routing shown in chapter 11 and Kubernetes in chapter 13 is probably even better.

resilience4j#

Netflix does not invest in Hystrix that much anymore. They suggest using resilience4j instead, which is a very similar Java library that supports typical resilience patterns.

Consul#

The Consul example (chapter 11) uses:

• Consul instead of Eureka for service discovery
• Apache httpd instead of Zuul for routing
• However, this project also uses Hystrix for resilience
• and Ribbon for load balancing.

Consul supports DNS and can handle any programming language as implemented in the Consul DNS example. Consul Template offers the possibility to configure services with Consul by filling a configuration file template with the data from Consul. In the example, Apache httpd is configured this way.

Eureka has quite a few advantages over Consul. Apache httpd as a web server is familiar to many developers and might therefore be less risky compared to Zuul. On the other hand, Zuul provides dynamic filters that Apache httpd does not support.

Kubernetes#

Kubernetes (see chapter 13) and a PaaS, such as Cloud Foundry (see chapter 14), offer service discovery, routing, and load balancing. At the same time, the code remains independent of the infrastructure.

Nevertheless, the examples in those chapters use Hystrix for resilience, too.

These solutions require the use of a Kubernetes or PaaS environment. Thus, it is no longer possible to just deploy some Docker containers on a Linux server.

HTTP proxy#

Functionalities like load balancing and resilience can be implemented with an HTTP proxy instead of Ribbon.

This is a further development of the sidecar concept. An example is Envoy. This proxy implements some resilience patterns. Envoy is also part of Istio and is used as a sidecar in Istio application.

Istio is a service mesh that supports many technologies for the operation of microservice systems.

With a proxy, the application itself can be kept free of these aspects. Apache httpd or nginx can at least implement load balancing. They could also provide basic features of a sidecar.

Atom#

Asynchronous communication (see chapter 6) seems to be a contradiction to communication via a synchronous protocol like REST. But Atom (see chapter 8) can be combined with concepts from this chapter.

Atom uses REST, so the microservices only need to implement other types of REST resources.

A collaboration with messaging systems like Kafka (see chapter 11) is also conceivable.

However, in this case, the system not only has the complexity of the messaging system but must also offer a REST environment.

Frontend integration#

Frontend integration (chapter 3) works on a different level than REST and can be combined with the Netflix stack.

In particular, integration with links and JavaScript (Chapter 4) is possible without any problems.

With ESI (see chapter 5) Varnish instead of Zuul implements routing. Varnish would have to extract the IP addresses of the microservices from Eureka.

However, this is not possible.

                                                 Q U I Z  

In the next lesson, we’ll look at some experiments that can be conducted with the Netflix stack.